Technical Field
This disclosure relates generally to information security on network-connected appliances.
Background of the Related Art
Security threats are continually evolving. With the rapid growth of cutting-edge web applications and increased file sharing, activities that may have been considered harmless in the past could become potential openings for attackers. Traditional security means, such as anti-malware software and firewalls, have become easier to bypass. Thus, there is a significant need for more advanced, proactive threat protection that can help provide comprehensive security against new and emerging threats.
Network-connected, non-display devices (“appliances) are ubiquitous in many computing environments. For example, appliances built purposely for performing traditional middleware service oriented architecture (SOA) functions are prevalent across certain computer environments. SOA middleware appliances may simplify, help secure or accelerate XML and Web services deployments while extending an existing SOA infrastructure across an enterprise. The utilization of middleware-purposed hardware and a lightweight middleware stack can address the performance burden experienced by conventional software solutions. In addition, the appliance form-factor provides a secure, consumable packaging for implementing middleware SOA functions. One particular advantage that these types of devices provide is to offload processing from back-end systems. To this end, it is well-known to use such middleware devices to perform computationally-expensive processes related to network security. For example, network intrusion prevention system (IPS) appliances are designed to sit at the entry points to an enterprise network to protect business-critical assets, such as internal networks, servers, endpoints and applications, from malicious threats.
The use of Secure Sockets Layer (SSL) and/or Transport Layer Security (TLS)-based encryption for network communications generally inhibits the ability to identify and mitigate threat traffic from within the network. It is now estimated that upwards of two-thirds or more of all business network traffic is conveyed over SSL/TLS. This means that organizations relying on network communications typically are unable to protect (from the network) the endpoints in their enterprise that may be susceptible to such threats. Indeed, the vast majority of SSL/TLS communications use only server authentication, i.e., the server is authenticated via the SSL/TLS protocols to the client, but the client is unauthenticated with respect to the server. This authentication asymmetry provides the opportunity for a process to interpose itself between client and server in such a way as to enable decryption of communications and inspection of its contents. Such a “man-in-the-middle” (MITM) process may be malicious, or it may be used for legitimate reasons, such as packet inspection (for threat detection).
Thus, it is known to provide a transparent (MITM) proxy between a client and a server that can be configured to create and manage two separate SSL/TLS sessions, one as the client to the target server, and another as a server to the initiating client. The intermediate proxy thus appears to the server as a client, and to the client as the intended server. Communications initiated from the client, and any responses received from the server, theoretically are then available for inspection and subsequent action. Current transparent proxies that operate in this manner, however, are bound to specific Internet Protocol (IP) destination ports and thus have the ability to act only on communications destined specifically for those ports (e.g., port 443 for HTTPS, port 636 for LDAPS, etc.) This requirement limits their effectiveness.
There remains a need to provide for a transparent proxy that can operate legitimately to intercept, decrypt and inspect traffic for any SSL/TLS communication, without regard to the destination port.